Any reason to not re-use the shim we already have in Django?

asgi.py imports django.core.handlers.asgi which doesn't exist in django < 3

sentry supports django ≥ 1.8

views.py wraps the asgi import in a try/except block
suppressing the inner import error
caused by the missing module in django < 3
to keep django ≥ 1.8 compatibility

To rely on the shim
I have to redefine the other half of the conditional iscoroutinefunction definition
inside the try/except block
which defeats the purpose of using the shim.

The "conditional import" phrase in the asgi module docstring
was, and still is, misleading people
into imagining an import within an if block.

Maybe I should rephrase it, since I'm touching this sentence in the chore commit anyway.
Examples:

This module imports django.core.handlers.asgi (Django >= 3), so
sentry_sdk.integrations.django imports it via a guarded import that
handles ImportError on older Django versions.

This module is imported from sentry_sdk.integrations.django using
try/except to maintain compatibility with Django versions that do
not provide django.core.handlers.asgi.

Separate commit or fixup on chore(django): Drop Python < 3.5 compatibility ?

But this alone will not be enough to address the same misunderstanding in the future
so maybe a code comment too in views.py is needed.
It's obvious what the code does but not why its here and not there.

Duplicated from asgi.py because that module is not importable on Django < 3.